Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. Now, 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time.
The added chapters contain (1) a crisp condensation of all the propositions asserted in the original book, including Brooks' central argument in The Mythical Man-Month: that large programming projects suffer management problems different from small ones due to the division of labor; that the conceptual integrity of the product is therefore critical; and that it is difficult but possible to achieve this unity; (2) Brooks' view of these propositions a generation later; (3) a reprint of his classic 1986 paper "No Silver Bullet"; and (4) today's thoughts on the 1986 assertion, "There will be no silver bullet within ten years."
March 14, 2019 Subject:
Learn To Avoid Management and Programming Fads
More than 250,000 copies were printed, and yet, that was not enough to spare me countless programming and management fads. So popular was this title that it earned a 20th Anniversary Edition and still, buzzwords like "pair-programming," "open workspaces," "test driven development," and "military style management" forced their way into my vocabulary.
Frederick P. Brooks, Jr., in 1964, managed the software side in the creation of the IBM 360 Mainframe Computer. Working on the famed project also afforded him a view of the hardware management side, and by way of comparison, he noticed that no developments in software could, or ever would, improve productivity, reliability, and simplicity in the same way hardware improved with advances in electronics, transistors, and large-scale integration. Noting Moore's law, Brooks writes "We cannot expect ever to see two-fold gains every two years."
The essays in The Mythical Man-Month shed light as to why programming is hard to manage, but not in a guru-like manner. Rather, Brooks writes from a position of humility. Of the IBM 360 Operating System:
"... the product was late, it took more more memory than planned, the costs were several times the estimate, and it did not perform very well until several releases after the first."
The essays can be enjoyed in any order, and three have resonated with me. "Chapter 3 The Surgical Team" describes why a balanced team matters, and Brooks asks who is the surgeon and who are the nurses and anesthesiologists on the programming team, how is the work divided, and how does the group communicate?
Brooks found small teams very effective, but the challenge was scaling them up for a project as large as the IBM 360. This was his thesis, and the remaining chapters discuss various techniques at coordination and not succumbing to The Second-System Effect -- another of my favorite essays -- described in Chapter 5. There he writes "The second is the most dangerous system a man ever designs."
An architect building his first system would be circumspect, given his inexperience and the unknowns. He would be careful and restrained, and set aside bells and whistles for perhaps a subsequent release. Not so with his second system, where ambition and hubris could blur, and where temptation would be high to incorporate functional ornaments, and to ignore changes in the technology landscape from when these features were first conceived.
How does an architect avoid the second system effect? Brooks dryly responds "Well, obviously he can't skip his second system." For specific measures, go read the essay for yourself.
Finally, I'd like to point out "Chapter 16 No Silver Bullet" which was added for the 20th Anniversary Edition. Here, Brooks indulges in a wager of sorts, predicting "that a decade would not see any programming technique that would, by itself, bring an order-of-magnitude improvement in software productivity."
Given that the Anniversary Edition was published in 1995 and it is now 2019, and given all the fads I have endured in between, I'd say Brooks won handily. Although an order-of-magnitude is a lot to ask in the software world, No Silver Bullet also tries to identify helpful and unhelpful trends. Of the helpful group, Brooks was prescient regarding Agile Methodology, identifying two of its components:
1. Requirements refinement and rapid prototyping
2. Incremental development -- grow, not build, software
Yes, Agile is a buzzword, but showing promise, it is not a fad. And like Agile Methodology, Brooks argues that the most important component to a software project is people rather than process. Ultimately, bugs, core dumps, and blue screens do not respond to demands, death marches, or heroic measures. They respond to competence and time.